In many types of operating systems, a variety of system services may be used in operation to achieve various functions. The service processes of some system services used to provide network services must be restarted to complete the configuration file reloading or the service process updating.
Taking the LINUX HAProxy network service as an example, this network service is implemented by using the SO_REUSEPORT option. After binding the newly created service process to the same network address (IP address) and network port as the original service process, it listens to the socket of the newly created service process. When a new service process is created, a notification signal is sent to the original service process to close the listening socket on the listening port. However, when both the newly created service process and the original service process bind to a same IP address and a same network port, and the listening socket of the original service process is not yet closed, the first packet (SYN packet) of a new connection request from an external client has an equal probability of being assigned to either the new service process or the original service process according to the implementation method of the existing LINUX kernel SO-REUSEPORT option. When the SYN packet is assigned to the original service process, and the listening socket of the original service process is immediately closed, based on the TCP protocol, the operating system will send a reset packet (TCP RST) to the external device to reset the connection.
Currently, some solutions exist for the problem described above. For example, a filtering rule (iptables rule) may be configured during the service process reloading to discard newly received SYN packets. According to the TCP protocol, after not receiving the SYN/ACK packets for a period of time, the client resends the SYN packet to reset the connection. By using the above solution, although the new connection will not be reset, it takes a long time, usually longer than about one second, for the client to wait for the connection timeout and to resend the SYN packet. While the service process reloading time is often only tens of milliseconds, the TCP connection delay is relatively long.
In another solution, LINUX traffic control tool (TC, traffic control) is used. Firstly, a filtering rule is used to mark the new SYN packet sent from the client. Then, the new SYN packet is temporarily cached by the TC. After the service process is reloaded, the SYN packet cached by the TC is released. Although the above solution has a relatively short delay, the applicable scenario may be limited because the TC tool can only be used to control the outflow of data traffic.
The above described problem of long delay in system service caused by reloading of the system service has not been solved effectively.